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I. INTRODUCTION 


During the early 1960's when the dual state third gen- 


eration conputers were develoned,the concept of virtualiza~ 


tion was born. Little did one recoaqnize the potential benee- 


PY tS 


oT Faoplig tCransitiom thot would soon takeVoePace Wim the 


comouter field in the area of virtual machines. 


may 


EVEN though this rao1id change and increased comoiexity 


lead to the frustrations expressed by John Gosden, Vice 


President, Eauitable Life Assurance Society [18). 


"All of these new announcements are a nuissance. 
We'd rather be aetting on with doing productive 
work than trying to keeo aliaqned wd th tne 
industry's technoloay.”" 


However, the virtual machine concept has arrived ana is here 


to stay. Robert P. Goldberg [11] notes that 


eV¥Yirtual machines have finally arrived. Dismissed 
for 3a number of years as merely academic curiosi™ 
ties, thev are now Seen as costreffective tecn~ 
niques for oraanizina commuter systems resources 
to provide extraordinary system flexibility and 
support for certain uniaue applications.” 


and Phil Rookman, Presidents Innovation Data Processing [18) 


Satirically comments 


The current statetofethe-art cf virtual computino is 


mn 


Vat oustecomeut ing 1S complicated, but if ites 
Srirolrewey you want; -aet a bank of 140i's." 


cil 


Vv) 


its infancy and its potential is rine for taopingr esnoe- 


cially tin an educational institution. 





[net hee moe Fe otf 1974 and early 1975, the Naval Poetoqradu- 
ate School acauired two Digital EGuionent Corporation 
PDP-11/50 computers as 8 part of the Signal Processing and 
Disolay Research Facility. It wili also serve as a vaiuable 
tool for the computer science student. 

With the enchancement of virtualizations, this comouter 
system would increase in both flexibility and potential 
uses. Virtual machine systems can be used {to resolve a 
number of problems that face a stucent of computer science. 
All students could be given their own virtual computer for 
exploring new ideas and concepts. the student could imple 
ment and test software from the basic hardware level to the 
operating system level without the fear of destroying or 
interfering with the real system. Courses can be made avail- 
able where the fundamentals of edvanced softwure and the 
desian and anaiysis of operatina systems are accomplished in 
a ‘'handseon’ environment. 

Besides an educational need for virtual machine's there 
exists the oproblen of security and privacy. Computer tech- 
nology has spawned a whole new field of crime and generated 
a series of probletms for both desianers and users of infor 
mation systems. There are truly very few systems that can 
be classified as secure. Particularily in the military en 
vironment, Security 1S a ever present problem and a inajor 
concern of students whe will leave this educations} insti 
tute anc work in a military computer installation. The vir= 


BUoneed # coOnnmuiiher holds areat opomyse as th@@solutien to 


this ever growitmga problem. It woutn for exanmnler be possible 





for the PND-11/59 to interaqrate classified and unclassified 
processes without deaqrading the performance’ of the system 
and without the fear of posstbie compromise. It would also 
eliminate the the current locked door ‘'monoprocessing' = en- 
vironment policy for processing classified jobs. 

Another need that can be solved by using a virtual com- 
puter 1S In system develooment. New enhancements to the 
operating system could be throughly tested and debugged in 
"dey light hours’! and in a multiprogramming environment 
before being place ‘on-line’. The concept of virtualization 
1S truly an exciting area of computer science and one in 
which the effects on the data processing community are just 
beginning. 

The remainder of this thesis is divided into five addi- 
tional chapters. 

Pome manter liy stne CacxorounNMG and princioles of vVigtue l= 
yZation are mn to develop a basic understandina of tie 
virtual machine and the current terminology associated with 
Hee A Glessary (Apoendix A) is provided for the convenience 
of the reader. 

Chaoter J1I1 oatives a summary of the architectual design 
of the POP=#11/59 family of computers and highlights some of 
the unsuitabilities of this tyne of architectural desiaqn 
for virtualization. 

Chanter IV presents the problems of virtualizing the 
PDP=11/50 and examines some possible solutions to these 
problems to include recommended milestones towards the ulti- 
mate goal of a fully virtualized PoP-11/50. 
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The selection of an anproach to virtualize the PDP=-11/50 
and implenrentation of this anoroach is wresented in Chapter 
Ve. A user manual CApoendix 0D) is also provided. 

Both chapters IV and V are self-contained and those’ who 
are knowledgeable about current virtual machine aonlications 
and technoloay should be abie to Skip directly to these sec= 
tions. 

Chanter VI summarizes the conclusions of this implemen- 
tation and contains Some suggestions for further develop= 


ment. 


| 





PI. VIRTUAL MACHINES ~- PRINCIPLES AND TERMINOLOGY 
A. PRINCIPLES AWD TERMINGLOGY 

The virtual machine can basically ne pictured as an imac 
Qinary ceny of Some real existing computer system but with 
Micmcopcei \ty Of “execmutangereal orogmams . This Gmique and 
rather new idea has irtroduced to the computer world the 
concept of multicenvironmenting as compared to multi~ 
programming and multiwnprocessina. In extending the basic 
idea af the virtual machine, one 1S lead to the realization 
that one real comnuter can create many imaginary computers, 
each of which nay have different herdware characteristics 
and devices. In addition, each imaginary machine may support 
different oserating systems. 

"Basically a virtual machine 1s a very efficient Simu- 
lated cony for copies) of the bare host machine [13]". 4 
bare host machine 18S simply a machine without i1tS accom 
panied software, 1e@. ODerating system. If we inctuded the 
operating system's instruction set (system callsr T/Ui's , 
etc. ) stong with the basic hardware instructions 
(MOV,B8R,v,etcw.)- we have introduced the instruction set for 
the extended machine 1i.@er the bare machine plus aperating 
system 1s the extended machine. 

The virtual machine may be further defined as an effi> 
cient, isolatedr duolicate of a real machine. It first must 
be efficient, meaning that the proarams executing under the 
Virtual machine should basically run at speeds comparable to 


execut10n On theen@a! machine. This attribute of a virtua! 





machine makes it reasonable to run apOdIee Ven type jobs on 
the virtual) machine. 

The efficiency asnect of the virtual machine 1S reaiized 
Mee having the majority of instructions of a program running 
on the virtual machine executed directly on the real host 
comouter. ThIS concept rules out traditionsl emulators and 
complete software interpretors, for both methods demand 
total interoretation of all wrogram instructions. 

Secondly, the reason the virtual machine must be isolate 
ed trom the rest of the system 1S to inSure that it has com- 
olete control over managing ifS own systems resources, and 
that no unintentional interference exists between the rea! 
and virtual system. 

Finaliys the virtual machine must produce a duplicate or 
essentially identical environment of real machines to make 
ime oractical to run) real jobs on them. "Since a virtual 
machine is 3a software-hardware duolicate of a real existing 
computer system there is always the notion of a real comput~ 
er system or real machiner whose execution is functionaily 
equivalent to the virtual machine (13)." If one must modify 
@ job to be executed on a virtual machine because the virtue 
al machine is slightly different from the real machines, then 
the virtual machine concent has loss its beautysr value, and 
meacticality [i151]. 

Dt. shoulG pe oCby1i0uUs that certain types of instructions 
can not be altowed to be executed directly but must be simu- 
lated by the virtual wnachine. The job of identifying and 
{rapping that type of instruction 1s the heart of the 


ee 
a} 





virtua: machine. The program that executes on the real host 
machine creatina the virtual machine environment 1S caitled 
the virtual machine monitor. Its function is to be the 
software interface between the real SyStem and virtual sys- 
tem. 

Fiaures 1 and e {3) illustrate the basic differences 
between the conventional computer system and ae virtual 
machine organization. The conventional dual state extended 
machine architecture contains only one basic machine intere 
face which can supoort many user programs but 18 only capa 
ble of running one privileged software nucleus at a given 
time. As contrasted in figure er the virtual machine ap 
proach, the wirtual machine monitor creates additional basic 
machine interfaces which are functionally identical to that 
of the real machine. Thus any orivilegeo software nucleus 
that will run on the real machine will execute on the virtu~ 
al machine. [It tS interesting to note, that the privileaed 
Software nucleus hss no way of knowing whether it is betns 
executed on the real or virtual macnine. 

Figure ee should not itimoly that the basic machine inter~ 
face supported by the virtual machine monitor must be ident 
ical to the interface of the bare machine that the virtuai 
nachine monitor runs oan, ieeeo virtual LOM S/ 5605 50 mead 
not be producea on a real $/560 50. However, when the inter- 
face is not identical they wilt be, at the minimum, of the 
same comnuter family. "hen two interfaces are comoletety 
aie rent ©1184 S/460 versus BURRUUGHS 6700) then emulation 
or simulation must be employed to map the one systen 
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atemmcecture Imto another ditferent architecture. 

The question that might be logically asked st this coint 
is: "Are there any restrictions on the type of orograms that 
can be orocessed on a virtural machine?”. Surorisingl ys 
there is basically only one type of program that. will even ¢ 
execute oroperly on the virtual machine and that is a4 prom 
gram with timina derendencies. This type of program while 
once pooular 18S now extremely rare. Reference ec4) provides 2 
detailed insight into this area. 

The virtual machine can now he formally defined as fal~ 
lows (24) 3 

"A virtual computer 18 a hardware-software dupii~ 

cate of a real existing comouter system in which a 

statistically dominant subset of the virtual 


processor's instructions execute directly on the 
host processor in native mode." 


The method of producing a virtual machine to meet the 
above stated definition may vary areatly. The method woud 
depend on such things as the specific brand and modei. sf 
commuter, the degree of efficiency requireds and tne tne 
maui ty of the programmer of the virtual machine monitor. 
There 8 no one best aoproach or method. The virtual 
machines that have been oroduced to oaate though, can be 
categorized Into general tyres depending on the method of 
implementation {3,713,14). 

A tyoe I monitor is illustrated by figure 2. Here the 
Virtual machine monitor runs directly on the hare machines 


where as the tyne II monitor Cfiaqure 3) runs on the extenced 
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machine under an operating system. 

heey Scull MOnrtor S Only TUMectlem 1S te produce one or 
more virtual bare machines which wilt support any operating 
System that the real hare machine would support. 

The type II] monitors on the other hand; can take advan- 
tage of the services provided by its operating SyStem. For 
instance, such features as the memory managements, the actual 
paging mechanism, and [/0 operations of fae operating system 
can be used. 

vinem the virtual maG@hine is identical to the host pro- 
cessor then we Say that the virtual commuter system 15S 
Sevt=virtualizing. “hen it 318 not +dentical, then the wvirtu- 
al machine musts as earlier stated, be of the same orocessor 
mamyiy as the host machine and is said to bé family virtuael= 
izing. An example of family virtualizing is an IBM s¢vstem 
370/155 as the host machine which is Supnorting a virtual 
system 360/50 machine. 

One very apoarent benefit of family virtualizing is 17 
upgrading the computer in a data processing installation. 
Here the old system could be virtualized to process a}! jobs 
thet have not been reorogrammed fo meet the new Systems 
requirements. Reprogrammina then would not be a critical 
mactor but could be accomolished in a timelyr directed 
manner, Taw tacts some application programs whitch are pro- 
cessed very infrequently may never be selected for repro- 
gramming. 

RecurSive virtualizin s is when an additional copy or 


Copies of the vitual machine monitor run on the virtual 
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system or systems that have been produced by the host com- 
puter. We have then in effects produced another level of 
virtual machines. Fiqure 4 illustrates this recursive pro- 
pertys and the concepts of levels of virtual machines. 

It is interesting to note that recursive virtualizing is 
Ssupoorted only under the self-virtualizing type system. The 
main reason for this restriction is the fact that the virtue 
al machine monitor is tailored to interface with a specific 
model of conouterr and therefore, it is only possible to run 
the monitor when the identical interface 1s oroduced. 

One can See that this property is indeed recursive, for 
level Peer auipe 4 1S sanotnee Yirtual machine moni toc veme 
wena have im etfect Tecursed again and produced a third 
level virtual machine and so forth. Tests have successfully 
been conducted over a six level recursion (12). 

One main advantace of practical importance in recursive 
Martcualizina is the ability to test and modify the virtual 
machine monitor itself without interfering with normal proe 


cessing. 


fee vo 1 © REQUIREMENTS FOR VIRTUAL MACHINE SYSTEMS 

Since the masarity Ofmsnstmuctions of application oero= 
qarams running on a virtual machine are going to execute 
directly on che host commuter without any software interven> 
tion, a method must be derived to trap only those "critical 
instructions" that mnust not be allowed to be executed, Ber 
fore adoressing this ttagmerag MFOCeSS, more fundamental 
questions should first be considered, namely "What is a 


2G 





me VE |i 


VIRTUAL RECURS 
—_ 
BARE MACH. | 






VIRT. MACKH 


| 
Uo Ei PR CiG : 


FIGURE 4 


21. 





iON 





Gpitical imstruction?” and “How can ome identify them?". 

Basically the third generation of comouters created two 
distinct processor modes of operation (privileged = 'supere- 
visor’ and nonprivileaed - 'program'). The supervisor mode 
permitted certain ‘privileged’ instructions to be executed 
which are denied execution in the user mode. Priviteged 
instructions then are those instructions which are allowed 
to be executed in the supervisor but not in the orogran 
mode. These privileaed instructions tynically control crits 
ical system features such as testing and Vrmee ta cong 
input/outout facilities or modification of address manning 
mechanisms. When the user requires the execution of a 
Poivitvegea instruction the user program executes a suveryi= 
Ser call to the om@rating system. This priviteged instruc” 
tion is then executed on behalf of the user program. 

MEOtTOSSOr MoObert FeonGold5erq tmohis Ph.D thesis 41S), “on 
vietual machine architecture defined the critical iwnstruc~ 
moms as the following: 

SiGe MSTUNVe IMStTMUCTIYOM 91S an instruction 
which, because of 3rd generation virtu3al machine 
software construction will give incorrect results 
if permitted to be executed directiv on the host 
computer". 

It 18 now obvious that sensitive instructions encoun- 
tered aim the virtual System cannot be allowed to execute 
directly, since the execution of sensitive instructions 
could prevent the correct interpretation of certain instruc- 
BONS « 

He states the key to implementing a virtual machine on a 


Ce 





Ried cemgeration system 12 to erovide complete functional 
equivalence with a real nachine without allowing the direct 
execution of sensitive instructions. 

Sensitive Instructions are Gividedod into two general 
typesr namelyr, control sensitive and behavior sensitive 


mast ructionS. 


1. Control sensitive instructions are those 
instructions which control the resources and en= 
vironment of the system. Examples of such instruc 
tions are those which attemot to change available 
memory, start an I/0 operation, or change the pro 


cessor node. 


= 


ec. Behavior Sensitive Instructions are those 
instructions whose execution depends upon their 
location in real memory. An example of such an 


instruction is the system/360 LRA Cload physical 


address) instruction. 


The machine instruction repertoire of the host computer 
system must be individualiy analyzed to determine their sen~ 
Sitivity. Each instruction should be questioned as to wheth>- 
er itS execution could nroduce a vossible erroneous” results 
1f allowed to execute 31m the unorivileged mode. This tden= 
tification and enalysis appears to be like a fairly simole 
procesSre but in reality vefore this can be accomolisheds a 
thorough understandina of both the machine language and 


hardware character: stics ust oe mastered. 


™N 
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Unce the sensitive instructions have been identifed, it 


1S now possible to determine if the computer system will 
supcort a virtual machine. Professor Goldberg's First 
Theorem on virtualizanility gives us this answer (24). 

"THEOREM 1 2: For any conventional third generation 

computer, a virtual machine monitor may be con- 

structed if the set of Sensitive instructions for 

that conputer 18 a Subset of the set of privileged 

instructions.” 

The basic philosophy behind Theorem 1! is the following. 
If all sensitive instructions are a subset of the privileged 
instructions, then the host computer haS a very convenient 
builtwin trarping method. Any attempt to execute a 
privileged instruction in the program mode will generate a 
machine interrupt. Thereforeys 1 f the virtual machine's 
orivilegeos er: 1S rUNNiIng 1n the Program state then an 
interrupt will he generated when the virtual machine's 
operatina system attempts to execute any privileged instruc= 
tions. Since the sensitive instruction is a subset of the 
privileged instructions sets it is just a matter of checkina 
to see if the privileged instruction causing the interrupt 
is sensitive. 

This class of interrupts can then be turned over to the 
virtual] machine monitor for servicing. If it 18 a Sensitive 
mNstruction tnat generated the interrupt then it will = be 
Simulated. If nots it wili be returned to the host operating 
system for execution. Fiqure 5 illustrates this interaction. 
The interested reader shauld refer to reterence (24) for 


Breof of tTheoren i. 
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This rather simple theorem suprisingly croves that very 
few third generation architectures are virtualizable, for it 
only tekes one Instruction to cause the monitor to be 
forced to interrogate all instructions to prevent the execu- 
tion of the one exception. This of course would cause the 
virtual machine to lose its efficiency and value. It should 
be realized, however, that third generation computers were 
not designed to supovort yvyirtual machiness, and it is their 
gual state nature that brought about the virtual machine 


eoemeenpt 1n the first place. 


(eee HYGRID VIRTUAL MACHINE SYSTEMS 

Since the majority of third generation computers are not 
virtualizable the hybrid-virtual machine monitor was intro- 
duced. Wer enero ve instructions are further classified 
into two aroups depending on where they can be located, ji-ee 
are they only tocated in the supervisor area of coding 
(Supervisor sensitive) or can they be in the user area Cuser 
sensitive)? 

Once the user and suoervisor sensitive instructions are 
identified then Goldbergq's Third Theorem can ne applied, 
which is the following {24}: 

Pie eORE“M SS Aghyobrid virtual machine =menitor may 

be constructed for any conventional third gqenera= 

tion machine in which the set of user sensitive 

Mgseruct | OWomeme a SUbSet of the set of privileged 

iOStCUGhEIOnNS . 

The main difference then between the virtual machine and 
mie  mybrid virtUal machine is in the degree of instruction 
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intcenretation. In the hybrid virtual machine al! instruc- 
tionsr privileged or not, in the virtual Supervisor mode are 
interpretead. User sensitive instructions will be trapped as 
previously nentioned. 

Figure 6 18S an overview that compares instruction in- 
teropretation versus direct instruction execution for normal 
processingr virtual machine processinagr hybrid processingr 
end for comolete simulation. It should be remembered that 
the more time spend in interpretation the slower the execu 


tion of the job. 


Dee THE VIRTUAL MACHINE MONITOR 

The virtual machine monitor controls the overall virtual 
maemnyme System. Ihe monitors main functions are to create 
the virtual machine or machinesSrs, to monitor and allocate 
their resources, tc interrogate all trapped instructions for 
Sensitivityr and to simulate the execution of the sensitive 
oietructions. 

the virtual machine monitor's software 1s composed gen= 
eralty of three Groups of program neGues olus numerous cons 
trot tables (fiqure 7). The three oroups are the disratcher, 
allocetorrs, and the interpreters. The control tables depict 
al) the virtual machines resources available and their 
current status. These tables are similiar to the normal 
Operating system's tables and contro! blocks. 

Yhe dispatcher is the ton level control module of the 
mim tual macnimne manitor. It 1s the initial erogram that 


receives the machine mterruots and determines et the 
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instruction that 1S trapped is sensitive. Jf it is Sensitive 
then the dispatcher decides which modules to call to sere 
vice this action. If it tS a reSource request or a resource 
modification, then the dispatcher will invoke the allocation 
moagutes tf the action calls for a Sensitive instruction to 
be simulatec tnen one of the interpreter mocules will be 
called. 

The allocation module is the main keeper of the control 
tables for the virtual machines. It is through this module 
that all the virtual machine devices are created and con= 
trolled. When the virtual machine nonitor 18 SUuBpOorting mul@~ 
tiple virtual machines, the complexity of this module is 
significantly increased. It now must keen track sevoarately 
of the individual resources of each virtual machine. 

The eet qroup of proaram modules that make up the vire 
tual machine monitor 18 conwnosed of many individual modules 
called interpreters. There 1S generally one interpreter 
Goutine for each identified sensitive instruction. Each 
interpreter routine will Simulate an instruction execution 
by changing the stete of the virtual machine so as to rer 
flect its actual execution. 

4l1 software = be it an operatina system, apolication 
oroaram running ee oe operating system, or a standalone 
program executina on the virtual machine =~ must execute in 
the nonprivileged program mode of the host computer. This is 
essential so that the real machine's interrupt can trap sen= 
Sitive instructions, Poeschouna@ene ObVIOUS “tnat tauetyoe 1 
Virtual machine monitor must execute in the Supervisor 
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Stater since it is in facts the total onerating system for 
the real hardware. The type II virtual machine on the other 
hand, has a choice between supervisor and proaram state. 

If a tyne II monitor is allowed to operate in the super- 
visor state, then the relationshio anc coordination between 
it and the onmerating system must be carefully thought out 
and designed to insure that there 1S no unintentional m~ 
terference. lf the monitor 1s executed in the privileged 
mode, then it could execute within itself the privileged 
instructions that may be required to be actually executed 
after either being trapped or required by some interpreter 
module. It would thereby save the time of requesting and 
waiting for the operating system to execute them, 

ay on the otner hand, the monitor is running in the pro- 
gram state then the interface problem with the operating 
system 18 nonexistant. All privileged instructions that are 
required to be executed must be turned over to the operating 
system. This wauld probably require some additional supervi-~ 
sor calis to be added to the systems but it would also make 


the virtual machine monitor smaller and less complex, 


FE. SOFTWARE AND HARDWARE REQUIREMENTS 
The hardware and software requirements of the host com~ 
cuter systen must meet the following criteria to adequately 


Support a virtual commuter system. 


i The method of iNmstruction execution of 


non=priviteged instructions in both supervisor and 


| 





been 


bett 


Comc 


program state must be roughly equivalent. This 15 
Important hHecause the operating system of the vire 
tual machines, which normally operates in the Su 
pervisor stater wili be executing 1n the proaram 
state. There is also the reverse problem of the 
privileged instruction in the program state not 
causing machine interrupts. For example, in the 
POPseeetd family of comouters certain instructions 
are iqnored if they are encountered while in the 


orogram state. 


ce A method of automatically signalling the 
Supervisor when the virtual machine attemots to 


execute a sensitive instruction must be available. 


— 


Sie A method of orotectina the supervisor and 
any other virtual machine must be available to 


insure isolation of all systems. 


4. The host computer should Support a page 
or segmentation type virtual memory system to ade- 
quately give the virtual machines tneir own virtu 
al memory required to hold its virtual operating 


system olus 1tS own arplication proarams. 


ADVANTAGES AND APPLICATIONS OF VIRTUAL MACHINES 


The advantages of a virtual machine have intentionally 


Pent. surit1 Nowe because many of the benefits can 


er apareciated once one has a good understandina of 


epts and workings of virtual machines. In facts hbeceuse 
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virtual machines lend themselves to So many gcractical avnpli~ 
eattons, wVnIS ute lt by TamMy ComuuLer experts that the “next 
generation" of computers will be specifically designedto sup™~ 
port virtual machines. 

The Ole) ny oe nes a few of the more imoortant = ad- 
vantaaqaes and applications of the virtual machine (19). 

1. Software Develonment For The Systen Froarams. 

Because system programs cannot run under the normal 

operating system in a production tyve environments most sys 
tem progranming work must be accomplished tn a stand-alone 
environments and agenerally tin the middie of the night. lt 
also causes the system to be brought down which interfers 
with normal processina and is wasteful of system resources, 
not to mention the inconvenience for both System ang anpli- 
M@etcion orogrammers. Using a virtual machine for system 
software development eliminates that type of @ working enm. 
vironment. System enhancement, new operating systen 


e 


co 


releases, or In fact any software development can 
thorouaqhly tested and debugged on the virtual machine before 
being released. All of this can be accomolished curing norm 
mal working hours and without wasting system resources. 

ee iio GwOnmen Cente Conversion Problems. 

This benefit was earlier examined and can only be 
truly aporeciated when one has lived through a mass conver? 
sion effort. the ability to be selective on what programs to 
convert and not to be rushed in that conversion 1S alone a 
great advantage. 

concn Menno Ofelsssimilar Operat mma 
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Systems By Dit tanant Users: 


This application would be extremly useful to those 
data nmrocessSing installations that are charged with the 
responsibility of aaa ane: App le Cae software which will 
be distributed to many installations and run on a variety of 
computer sizes and models and under different operating 
evstems. In facts copies @f the actual operating System of 
the individual Installation ain which the program will be 
running could be sent to the testing installation. Then the 
procram could be executed on a virtual machine configured to 
the installation and tested under their operating system. 

Another benefit of running dissimilar operating systems 
iS computer backup capability. If an installation's comput@= 
er went ~down for an extended period of timer the instaliaz 
tion Pe iia <ceia process mecessary jobS on 9 virtualized 
system using their backuo installation's comouter. They 
could use their own ocerating system and configuration 
thereby avoidina the difficult tasks of temporarily nodify> 
ing or aeneratina operatina systems or programs generally 
required when one has to move their processes to anodther 
Pomput ere 

4. fTestina Future Hardware. 

The virtual machine aqives the installation the aoil> 
ity toa desianr develoo, and test programs that will be in- 
terfacing with new hardware before the actual hardware is 
delivered. in addition to hetping in the program develop- 
ment, it could have been used in the hardware selection croe 
cess. Different tynmes and models of hardware devices could 
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have been virtualized and tested for their anplicability. 
See stadt Network Facilities. 

The complicated nature of testing and implementing a 
computer network would be greatly simplified if many of the 
inter-comnunication sofiware buGs can be found and corrected 
on the system bhefore the actual implementation. 

6. Evaluation Of Proaram sehavior. 

The nature of the virtual machine monitor tends 
itseif to a type of oerformance monitorina, Detailed in 
teractions between the software and machine or between 
software nodules themselves can be tranpedre measuredsy and 
recorded to be tater printed out for detailed analysis. 
Changes could be implemented and measured again to check the 
improvement factor before making the real modifications. 

moe ccurity Ander vacy. 

The virtual comouter system holds great promise 1n 
the area of security and orivacy. As mentioned earlier: 1 
msoeamDossible for an operating system to tell if it is being 
executed on the real or virtual machine. Each machine vire- 
tuel 1S comonletely tsolated from each other so it would oe 
imposSible to sDy on or try to alter any coexisting machine. 

SE dUGAe TON. 

The ability for a student in the computer science 
field to be able to have his own computer and operating sys* 
tem 1S 8 blessing to both student and computer center 
manager. Here he can work with and alter on his own an 
operating system, without the underlying fear of destroying 
the real systems for the only way to truly learn about 
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js) ARCHITECTURAL DESC Uene PoP Si 7 50 

This chapter 1S primarily desiqned to highlight only 
certain areas of the architectual design of the PDP-il fami- 
ly of comouters. Attention iS mainly Given to ccmouter 
design characteristics which relates to virtualization orab= 
lems. It 15 not intended as a comniete or detailed analysis 
of the internal comouter workings. The interested reader 
will find a complete and detsiled description in references 
(7] and [8]. 

The PDP=-11750 iS a general purposes, interrupt drivenys 
three state computer, caoable of directly addressing e&x« 
Sixteen bit words of memory without the memory management 
uNIt, and 124k words with memory management. It contains two 
independent sets of Six general omrurpose registersr,three 
stack pointer registers (Cone SP for each State), anda pro» 
gram counter register (PC). 

The PDP=11/50 in addition to the optionel memory manage~ 
ment units supports an optional floatinra point processors 
and a host of peripheral devices. fhe system is designed ta 
Support & virtual memory multroracrumming environnent. The 
basic relationship of these different units are deonicted in 
mroure &. 

The general puroose registers are rather unique in that 
I17GO operations do not distturn their contents and secondly. 
they can be used in a diversity of register operations, 


cointerss 


ou) 
O 
vr 


namely aS accumulators, index registerSr st 
autoincremert and autodecrement registers. 
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The instruction set is probably the most powerful asset 
of the PDP-11/50 comnuter. The instruction set consists of 
over four hundred microproagrammed instructions. Instruc- 
tions are so flexiovle that a programmer has numerous options 
available for coding any Program routine. 

The architectural desian feature of the PDD-11 family 
of computers that distinguishes it from other DEC systems as 
well as from other computer vendors 31s the UNIBUS. The 
UNIBUS is a hiah speed (Cfive million bytes/seconds), 
asychronouss bidirectional channel that ties all system comm 
ponents together (figure 9). 

All memory and orocessors are connected to the UNIBUS in 
a reqular manner. The same addressing scheme is anolied 
equally well to a snecific devicer memory or processor. This 
gQreatly simplifies I/0 programming because the entire 1n~ 
struction set is available for innut/output routines. 

Machine instructions that effect the UNIBUS operetion 
or devices attached to the UNIBUS would qualify as sensitive 
mctructions.e 

The POP-11/50 18 a three state machiner as compared with 
the conventional two state (supervisor and program) opera 
tion. The three states or modes are kernels supervisory and 
user. Kernel mode programs are unrestricted in their use of 
the machine while the programs operatina itn the user. and 
Supervisor modes are restricted in the kind and number of 
instructions which may be legally executed. The supervisor 
mooe +s only slightly more oowerful than the user mode. 

It 1s interesting to note some instructions (CRESET,SPL, 
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etce)} are ianored if not in the kernel mode white other 
instructions CHALT) generate an interrupt. This inconsis= 
tancyr esoecially when encountered in the sensitive wnstruce 
tion set, adds to the comolexity of virtualizing the POpreii 
family of comouters. 

The processor status word (PS) is a special memory cell 
located in the upper 4k of the machine's memory. (The upoer 
Gk 1S not actual memory but addresses of device registers 
located on the device.) The current machine operation mode 
at any given instance 18 completely determined bv the 
Gumnrent mode bits ym the PSs. 

The PS may be changed in one of three ways: (1) Explici~ 
tyr by physically nodifing it via a normal machine instrucm 


ae 


Myon such as MOV. (2) Implicitly- through the use of one oi 
the eye nal machine instructions such as SPL-RIT,RTI which 
cause the PS to be implicity changed, and (3) Asynchronous~ 
lyr aS a result of an interrupt or trap. 

itive saorlity to exolicitliy modify the PS and in  fset to 
Go any actual I/O is a ‘function of whether or not the 
mpogram’s virtual address soace 1S mapped into that oortion 
of the machine's physical memory which contains the PS ans 
device registers. Programs operating in the user or super- 
visor mode are generally restricted in this manner causina 
for example, I/0 to be initiated only from the kernel ee 
eer. Figure 10 DUDE ie Giistets the real and virtual memory map. 

Instructions cadable of modifying the PS (CSPL-/¢RTI,-RTT) 
also qualify aS Sensitive instructions. This would inciude 
a MOV imstruction 1f allowed to access the I/0 nage. 
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tme [1/0 “structure om the POPmI1/50 is one of the true 
advantages ouilt into the system's architecture and can he 
one of the biggest disadvantages in virturalizing the sys- 
tem, depending on how the uoper 4k of virtual memory is 
mapped into physical address space. 

It would be highly advantageous if the uonwer 4k virtual 
addresses of a program executing on the virtual machine were 
allowed to nan directly into the physical I/0 pagers and the 
access contro! field of the page description reaister is set 
to abort all accesses. Thus this type of sensitive instruc™ 
tion 1S conviently traoped. IJf this is not the case then 
because of the flexibility of the instruction set and espe= 
cially if the program has no restrictions on the method of 
accessing the 1/0 page, then one is Jead to a one-hundred 
percent instruction interrogation and a large increase in 
fest rauction simulation routines. 

The design considerations for the asychronous interac? 
tion ovetween nodes 1s based around stack operations. A stack 
is a tenporay storace area Cone for each mode) used 1n 
subroutine and interrupt service linkaaqe. 

Individual proaqram stacks can be directed to start at 
any virtual address and can expand either upward or down 
ward, Any register can ee oe a stack pointer. The main 
register used by the system for this function is the stack 
pointer register (SP), which by deSign expands downward. AS 
ealier mentioned, there iS a Separate SF for each mode. 

Interruocts and subroutine linkage are very similiar and 
only differ in their method of invocation and the reaisters 
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that are stacked and loaded. Interrupts are forcea while 
subroutine linkage 15 controlied proqram transfer. In addi- 
tion, subroutine linkage only effects tne PC and not the PS. 
The action is wasically as follows: The old PS (Cif caused 
by an interrupt) and the current PC are automatically 
Stacked onto the new processor Stack and the new linkage 
mororgation (PS if required and PC) are placea in the regis= 
ters. 

AV interrupts are required to be simulated under a 
virtural machine, subroutine calls are not. 

This brief examination of the PDP=11/50 architecture 
@learly illustrates that the PDP=-11/750 was not designed for 
supporting a vitural machine Bee icot voae In facts without 
sianificant hardware modifications a true virtural comouter 


system can not resaiized. 
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IV. PROBLE™ DEFINITIONS AND POSSTOIE APPROACHES 

The current staterof-therart of computer science offers 
avariety of approaches that may be employed to virtualize a 
comouter system. Virtualization methods can range tron 
extremely exnensive and complicated hardware modifications 
to that of only minor systems changes to support a Jimited 
type JI virtual machine monitor. 

The first step in determining the type of virtualization 
approach sa USE is to examine the comouter manager's nplans 
and goals for the installation. Management's desires will 
automatically eliminate many of the possibie aporoaches. 
Thereforer a brief examination of the Naval Postaraduate 
eenoo!'s PDP-11/50 compute@p to include the cofputer’s en= 
vironmenter primary user and the genera) goals of the school 
towards the comouter system 1S in order. This examinatian 


will highlight the. inposed restrictions on virtuaiilzing the 


Systen. 
A. SYSTEM ENVIRONMENT 


ite Naval Pestgqraduate School has two POP-11/50 conput= 
ers anda wealth of periohial devices. These computers are 
not intended to serve the school in. a computer service 
bureau fashion, but are incorported into a computer research 
laboratory. 

The orimary research areas of thiS cComptter labors3tory 
are 31M the fields of operating systems desian and researches 
signal processindgs computer araohicsSr, and hybrid computina. 
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Tenpamery confiaugeton modificatyvons for a scecific 
research project offer no real problems. Periphertals can 
be switched between computers in matters of minutes to meet 
any new demands. This Versves}ity 1S moimly do to the stan- 
Gerd interface of the UNIBUS. 

Managements goals though-s are to have ali JI/0 devices 
and comouters tied together to sunmport a real timer mui- 
tiproaqrammingr multiprocessing operating environment. The 
general confiauration envisioned is schematicatly illustrat= 
ed in apnendix (8B). It is a general configurations since the 
wide range of activities + will continually demanding confi- 
@uration nodifications. 

A greatly enchanced version of the UNIX onerating system 
(called MUNIX) is being designed as the primary opcratinga 
system to enone the desired system environment. 

UNIX itself 18 a general purpose, nultiuserr interactive 
operating system developed at sell Laboratories. UNIX con= 
tains a number of sophisticated features generally only 
found on large systems, but with the surprising and unusual 
quality of simplicity and ease of use. 4&4 complete and excel= 
Lone abstract of UNIX is contained in reference 28. 

Even though UNIX is extremely powerful and versatile it 
would not meet the complete demands that would be required 
of the operating system. MUNIX is being develooed to meet 


those addition demands of real-time processina. 
[Se VbR TOAD) Zenon GOALS AND PROBLEM AREAS 
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The Naval Postgraduate School's desired goal in the area 
Ore Virtualization of the PDP=11/50 can be summarized as fol=- 


lowss 


is Achieve the capability to eroduce a virtu= 
alized PDP=-11/50 comouter that would support all 
available operating systems and be able to access 


any real or virtualized I/0 device. 


ans The virtual machine's efficiency would be 
sufficient to reasonadly execute most types of 


applications. 


3. Incorporate a complete debuaging aid fas 
elity to assist. the user tn executing and piro- 


gramming on the virtual machine. 


The decision was made that any implementation of a vires 
tual system would be requirea to operate under the MUNITX 
system. This thereby eliminates any tyoe I virtual machine 
monitor considerations. 

A futher decision and restriction was that the virtual 
machine monitor olus programs executing on the virtual 
machine would execute in the user mode and in a sinilar 
manner to any other process. 

This restriction imnosead a serious problem on referenc™ 
ing the I/0 paqe. Since the I/0 page comprises the upper 4k 
of the address svd0ace, al) programs on the virtuel machine 
would reference this smace for testina and excuting J/0. 
MUNIX,s, on the other hands uses this virtual address space 
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for the user Stack area. This restriction also imposes’ the 
problem of having two user mode processes executing con- 
currently and in harmony but at tne same time having one. of 
the processes (virtual machine monitor) be the Suvervisor. 
It was also decided that the virtualization design would if 
at all possibler- minimize modificaticens to the operating 
system, 

The main problem areas identified in both the hardware 
architecture and software restrictions can now be Summar- 


1zed. 


1. That a true virtual system cannot be i1n- 
coroorated on the PUP=181/50 teas det inecmipy 
Goldberg's Theorem 1, since ali identified sensi- 
tive instructions (Capnendix C) are not a subset of 


the privileced instructions. 


ee. That the identified sensitive instructions 
vary in their method of execution when encountered 
in the user mode. For exampler the HALT causes a 
tran, a RESET causes a Roop. and a RII 1s executed 


IN @ Normal manner; 1.-@-6 independent of mode. 


3. That the I/0 page accessing the user oro 
garam and the MUNIX user's space area are incompat= 


able, 


We. That the virtual machine monitor should be 
completely senarate from the !ob execurina on the 
virtual machine, 1ef. NOt IM the Same adudressing 
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spacer but at the same time have the ability to 
access and examine in detai! the processes’ regis>- 
ters, PSs and memory. The virtual machine monitor 
must also have the canobi lity of controlling the 


oroaram's execution. 


fae “MILESTONES 


The acheivetent and success of the desired goals reo 
quires a great amount of complex desians codingr and process 
interaction. This 18 especially true if the time span rea 
quired to attain these goals includes a series of program 
ming teams. A methodical plan must first be initiated and 
implemented in order to have the end product useable and 
etficient. tach hierarchical steno of the plan must be tlogie# 
cally develsnoed, flexibler and modular for good program con 
trol and documentation. The following outlines the essen 
tial milestones to meet the objectives of a truly virtual= 


mzeo PDP-11/50. 


STEP 1 = Develop the basic foundation and 
necessary tools to suoport a Jlimited virtual 
machine. The virtual machine would execute stand- 
alone processes subject to the following restric 
tions. Paest, Interrupt handling would not be 
included. Secondly; methods of accessing the J/0 
page would be restricted. Finallysy only those sen- 
Seaver imc oructloms tnoatware required for basic 


proaramn7ina be sinulated. 





SVG@eec = Develen and mcorporate a compolete 


interruot handling process. 


STEP 3 = Complete the simulation of all sensi~ 


wive- wmst cuCcCtTIONS. 


STEP 4 = Develop and inciude an efficient but 
unlimited 1/0 capabitity. The consolidated virtual 
machine monitor woulda now have the ability for 
Supporting a virtual machine that could process 


any stand-alone job. 


STEP 5S «+ Complete the final enchancements of 
havin the vVirttial mechame capable of supporting 


different onmerating systems. 


Meet sation of several virtualization projects at other 
institutions, in the area of man=hour development of a pro 
ject of this sizer estimates this effort to be approximately 
one to two years dependina on the implementation method. 
Our goal 1s to comolete the first inilestone, putting em= 
phasis on developing the toolss plus program modularity for 


ease of future enchancements. 


Dee JoolSigk APPROACHES 


To meet the required virtualization objectives of the 
Seno | z four possible approaches were examined. The apn 
proaches varied considerably in cost, sophisication, and 


implementation ease. Tne approaches were? 
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i Ne QuIre Tf “PoSstbtc, “vurcug! Machine mont 
tor software already develoned for the PDPe-il come 
outer family from anotner institution or sourcee 
This aonproach 1s the most t!ogical and has the 
greatest appeal in firsts not ‘reinventing the 
wheel’, and secondlys snending the majority pro- 
gramming effort on converting and adapting it to 


our environment. 


2. Acquire and implement necessary hardware 
modifications to the PDP=-1! system so as to im~ 
prove its virtualizable characteristics. A true 
and efficient virtual system can never be realized 
an a Pie tl commuter until the execution of all 
sensitive instructions in the user mode automati=> 
cally interrupt the system's processing. This type 
of modification of the hardware though, may lead 
to many undesirable Side effects. For example, 
vendor maintenance aareements may be endangered, 
plus the real oossibility of degradation of norma) 


processing. 


§$. All) programs to be executed on the virtual 
machine would first be examined by a preprocessor. 
The function of the preprocessor would be to iden- 
tify and substitute a arocessor trap instruction 
for all sensitive instructions encountered. 

This aporoach has the advantages of being the 
most cost sensitive and relatively easy to 
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implement but has three main disadvantages. First, 
the time spend for preorocessings secondly, the 
ease of anyone intentionally or unintentionally 
beatina the preorocessor since data and instruc 
Biions are intersoersed in a orogram and confusion 
between the two are easily made; finally, and most 
important, the inability of nrocessina a program 


which contains self=modifyinag code. This includes 


many operating systems. 


4. Implement sone extensive operating system 
modifications to ease the vyirtuatization effort. 

Although this approach is in variance with the 
restriction on minimizing onerating system modifi 
cations, some of the major problems could 0obe 
mecolived. FOr amStamce, it would be highly desire=- 
able to have the I/0 page eaevailsable to the virtual 
processes thus solving the I/G problem and either 
eliminate or relocate the user stacks. This would 
require the oneratina system to distinauish a real 
from a virtual orocess for apnpronriate stack han- 
dling and memory mappina,. 

Another very appealing imolementation method 
iS to have the virtual machine monitor execute in 
the supervisor node while the virtual processes 
run in the user mode, This would solve the 
memory address space oroblem and have the virtual 


monitor avove the user but less then the operating 
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system. This a}S0 would require extensive 


cations since MUNIX only uses the kernal 


There 


modifying 


the present time of the UNIX system. It is first, 


new to all 
which it 


system 1s 


are aiways considerable techinical 


any ocerating system. This is especially 


personne! at the schools including 
iS written In, but more imnortant 


almost completely undocumented. The 


effort to date has been in learningr document 


fying the 


more important areas of the system. 


mcodific 


and user 


the C~langquage 
tne operating 


majority 


1nNGr and 


oroblems 
true 


relatively 
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Ae SELECTION 


The prenrocessor approach was selected as the method for 
virtualizina the POP=-11/50. Although this method haS some 
Substantial disadvantages as outiined in chapter IV, the 
cost, ease of implementations and time limitations more than 
compensated for them. This method also AES hated in overcom= 
ing some of the conflicts and undesireable effects of run- 
ning under MUNIX and without making any modifications to the 
MUNIX systen. 

The search for existing virtual machine monitor 
software, for the PDP#11/50, identified only one other edu 
cational institution involved in this area. The University 
Omeealiforniar at Los Angelesp, under the direction of Pro- 
fessor Gerald J. Ponek is currently involved tn virtualizing 
a PDP-11/45 computer. One of their main research efforts to 
date has been in the area of computer security and the vir? 
tual machine. Their implementation method involves a type I! 
virtual machine monitor plus an additional olugeble hardware 
modification module, (the Virtual Machine Extenston - 
KBS11-A), desianed and manufactured for them by Digital 
Equinpment Coporation (DEC). Tne hardware module simply plugs 
into the systen when the virtual machine monitor 1S PUuNNING 
and efficiently traos all sensitive instructions. 

Professor Ponek was contacted for the possibility of 
uSINng any of their software modules in our virtual machine 
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monitor. It was decided that at this timer it would be very 
impractical since their virtual monitor is still in the 
developnent stage, written in a different languages and 
mostly undocunented. Professor Fonek did recommend thouah, 
that we purchase from DEC the hardware ‘virtual machine 
extension'. The virtual machine extensions option (KBS11-~4) 
is an available Digital Equipment Corporation option for the 
eep=t1/45 and PDP=-11/50 computers at a cost of $5995. Its 
specific function is to facilitate the writing of virtual 
machine monitor code. 


The KBSLiwA provides the following features: [10] 


Mitewlit PrROVices tthemobi lity to Creare Certain “con= 
trol= sensitive" instructions wher they are en 
countered in user and/or supervisor mode. These 
Instructions, characterized by the fact that they 
operate differently in user or supervisor mode 
than in kernel mode, are: 

Aine Malt elm ctinee t 10m Execution 

WAIT ~ Wait for Interrupt 

RESET = Reset the system 

RTI = Return form Interrupt 

RTT =~ Return from Trap 

SPL = Set Priority Level 

Mitt = 4ovearto Previous Instruction 

Soace 

MTPD = Move to Previous Data Space 

MFPI] = Move from Previous Instruction 

Soace 

MFPD = Move from Previaus Data Space 
In the virtual machine environment, these instruc> 
tions nust be trapoed and then simulated by the 
onerating software. To aid in the servicing of 
these instructions, the KBSiL1l-A hardware encodes 
each of these instructions into 93a unique 4Ybit 
number which can be read by the service routine. 
This eliminates software decoding of the instruc- 
tions. The snecified instructions cause a reserved 
LaStructi1on traOemeec tone 10. 


Ce It provides the ability to set un an alo 
ternate vector space to he used for traos an 
mterruots from user mode. The effect is to 


"G@ttset » by)l1000, cOOU0, or S000 (octal), any vec~ 
tor address generated while the processor is in 
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user mode. This 38S done so tnat 3s Supervisor pros 

oram can service certain trans from user programs 

directiy while still allowing the Kernel mode pro- 

gram full control of the system (Call vectors are 

mumecerne |] address space). 

CF It provides a User Stack Limit Registers 

Similar im Ooeration to the Kernel Stack Limit 

Register. Without this capability, the only other 

way of limiting the user stack 18 by means of the 

Memory Mamaeaqement Unity which limits virtual 

machine structure and flexibility.” 

The KBS1l17A option contains no operator controls, but is 
under full orogram control by means of three registers on 
the UNIBUS. The three registers are the following: 

1. VCSR VMX Control=Status Register = This 
( 


register contains Seven control bits to enable or 


disable the various extended orocessor features. 


a. 


ee VCODE VYX Reserved Instruction Code Regis= 
ter - This register contains a four bit code for 
easy identification of the instruction that caused 


the trao. 


3. VUSL VMX User Stack Limit Register = This 
register contains the user stack limit address 
which overates like the standard kernel mode stack 


mimic register. 


Nhen the K®BS11°A is disableds the KBS11"4 hardware has 
no effect and the processor operates as normal. eats 
hardware ootion solves all of the hardware problems and 
menads ytself for creat#ng & true virtual machine® The cost 
aa tivew KOSTA 1s curPpently the prohibitive feature, but 
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until this hardware ootion or one simibar to it 18 installed 
the aoals of the school toward virtualization wil} never be 


attended. 


Be. DESIGN CONSIDERATIONS 


With the objective of imelementing a basic virtualized 
PDP=#11/50 computer (chapter IV ~ first milestone), the fol 
lowing desian characteristics and considerations were adovot= 


ed. 


1. The virtual machine's configuration will 
consist of one PDP=#11/50 computer without a memory 
management uniter 32k words of memoryr and one LASD 


DECwriter termininal. 


2. Job processina will be restricted to stan= 
dalone jobs that have been preprocessed for sensi~ 
tive instruction substitution. Jobs also will be 
restricted in the method of accessing I/0 and in 
not using interrupt tyne processing. The ‘MOV! 
instruction emoloyina direct indexing will be the 
only instruction allowed to reference the I/0 page 
and the ‘HALTS instruction wil! be used “for exit- 


ing fron the user program. 


3. The debuaging aid will tnelude the follow= 
ing capabilities: (1} Be able to display the cone 
tents of the oaeneral registers, proaqram status 


word and menory. Memory may be displayed both 
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Sectaltiy “and Symbo lical ly: (?) Be able to modify 
any register or memory celi; (3) Provide the abil@= 


Tuy, tor breakpoint orocessina. 


4. The program will be written in the Ce 
language, be modular in design for ease of incor= 
porating enhancements and imoerst sncune and in 
corporate a built In Internal debugger that will 
UPON Command, give the value of the variables 


encountered throughout the proaram, 


Pee eMrPLEMENTATION 


1. Program Overview 
The virtual machine monitor consists of the foilow> 
ing functional units. (Figure 11 illustrates these function= 
al units and their relationships). 
@e Supervisor Monitor 
The supervisor monitor 18 the highest level 
module of the virtual monitor. It provides the main communi? 
cation between user and virtual machine. Jt acceots’~ and 
edits the virtual machine monitor commands and cal!s and 
Supervises their execution. 
be Preprocessing Monitor 
The preorocessina monitor editsr callSr ana monnm 
itors the preprocessor executions. 
Cc. Preprocessor 
The preprocessor 18 a3 completely self-contained 
module that examines incoming virtual machine job for 


58 





PROGRAM MODULE OVERVIEW 
VIRTUAL MACHINE MCONITOR 


SUPERVISOR | INTERNAL ! 
MONITOR PROGRAM 
DEBUGGER | 






PREPROCESSING EXECUTION 


DEBUG 
IMONITOR | MONITOR 


MODULES 





breakpoint 
modify 
PREPROCESSOR VMM 
PROGRAM | DISPATCHER 
SENSITIVE 


INSTRUCTION 
SIMULATORS 


a | 


MISC 
UTILITY 


FUNCTIONS 





FIGURE Il 
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@enstitive instructions and possiole substitution. Its out- 
put is a nodified executable (Ca.out) file and 4 Sensitive 
Instruction table. 
Ce xecut 1OM amon) Cor 
The execution monitor's function is to start or 
continue the executing of the job on the virtual machine. I¥ 
a breakpoint or sensitive trap 1S encountered tn the program 
the execution monitor receives the interrupt and calls tke 
dispatcher for servicing. 
e. Dispatcher 
The dispatcher determines the type of problem 
encountered in the mrogram and calis (Cif necessary) the 
required sensitive instruction simulator or breakpoint 
handler. — 
f. Sensitive Instruction Simulators 
These routines Cone for each sensitive instruc~ 
tion) sinulate the execution of the individual sensitive 
toastructions. 
ge Debug Modules 
The debug en oe available to the general 
user for assistance in orogram debugging and in examining 
program execution. 
he Internal Program Debuaqger 
When this iS activated, variable values used 
throughout the proqram are displayed to aid in gebugaingse 
This function tS not intended for the general user but y= 
stead for the virtual machine's monitor maintenance,y debuam 


Gingrs and enchancement verification, 
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jeo™Myscellancous Uttsi wey fFume|tions 
This is a general collection of utility func: 
tions used bv the main modules. 
PB eOUPe TY 1SOo Sone or 
The supervisor monitor (named ‘ttevmm') is a sma) 
simple routine which contro!s and directs the main flow of 
the progran, as directed by the user's commands. hte 4 Seat he 
highest level module of the virtua}! machine monitor and the 
one that 1s entered when the monitor program 1S executec. 
Its action is simply to wait for a user command, edit the 
command, and initiate a call to the correct module for pro- 
cessing. After the called process has completeds control is 
returned to the suoervisor monitor. The supervisor monitor 
then waits for the next command. 
ae foliowing is a list of the valid commands and 
their resnective functions. 


COMMAND . FUNCTION 


eerilex fy/n] ([b] Preprocess filex. ThiS com> 
mand has two ortional paramen 
ters. The first indicates 
whether the user wants to be 
informed when a sensitive 
imecruet 1oOn is encountered. 
The second activates the 
preprocessor's internal deo 


bugger. 


e Start or continue program 
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execution. 


ADDR Put @ breakpoint at address 
ADDR 
r Display all general registers 


plus the program status word. 


o ADDR # Display memory in octal start 
ing from address ADDR for 4 


number of words. 


s ADDR #2 Display the program symboili- 
cally from address ADODR for 4 


number of instructicns. 


ex VALUE Modify reaister X to VALUE 
(octal) 

or VALUE Modify stack pointer to VALUE 
(octal). 

PC ADDR Modify the oproaram counter to 


address ADDR. 


Poe VALUE Modify the program status word 


POmVMeuUeNCOCctal). 


mem ADDR VALUE Modify memory at address ADDR 


too VALUE Coctal). 


Enter internal deougq. 


a) fal 





x Leave internal debug. 


S Terminate tne execution of the 


virtual machine monitor. 
S4 Preorocessor 


The preorocessor orogram (named ‘'evmm001') is a self 
contained module whose function 1s normally required only 
once for each job processed on the virtual machine. Because 
of its infrequent user, the preprocessor 18S loaded into 
memory and executed only when needed. The preprocessor is 
called Vere he nie moc eS SiiiGusem Om it Om. The interaction 
between the preprocessing monitor and the preprocessor pro 
gram iS coordinated by a series of MUNIX system calls as 
Malet pated tant Voure le % 

The input to the preorocessor iS programs which are 
to be executed on the virtual machine. These programs must 
be in the form of an executable (a.out) file with non 
sharable seaqments. The user program inout is read into the 
preprocessor in blocks of Sie bytes for improved effeciency. 
The preoprocessor program examines and tests each oroagram 
instruction in the text seqment for sensitivity. If such en 
instruction is found the ‘TRAP! instruction (104450) re- 
mercess tt sand the Gensicive amstruction is then written in 
the sensitive instruction table. 

The ereprocessor program has three arguments. The 
first argument is mandatory and aives the name of the pro- 


gram (a.cut file) for preprocessing. The second arqument is 
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INTERACTION BETWEEN PREPROCESSING MONITOR AND PREPROCESSOR 


PREPROCESSING MONITOR 
EXECUTION 


FORK ( ) 


A new system process is created 
by copying the core image of the 


caller of fork. The new process 
1s the child of the old process 
the parent. 
PARENT (old process) CHILD (new process) 


| 


WAIT ( ) | EXEC (-VMPOCT} 

Causes the parent to Program -VMPOOI overlays 
to delay execution child and starts execution 
until the child at the beginning of the 


process has 
terminated. 


. 


Continues to 
execute 


: 


program. There 1s no 
return to the original 
child process. 


| 


~VMPOOI starts 
execution 


-~VMPO00O1 terminates 
(activates parent) 


FIGURE 12 


64 





optional allowing the user a choice of whether he wants to 
be notified when a sensitive instruction is encountered. 
(Default value is ‘do not notify'). when notification is 
desired, the sensitive instruction plus the five previous 
instructions of the mrogram ana their lecstion ere 
displayed. It is at this time that the user can exercise the 
option of agreeing or disagreeing. If the user agrees, the 
‘TRAP’ instruction will be substituted, otherwise no substi 
tution will be made. It must be emphasized that tin the nor 
tificetion noder the user decides if a sensitive instruction 
has been encountered. The final optional argument is the 
internal debug switch for the preprocessor (Default value 
Bes mo debug’). 

Tite. sJISk Vanaeest Rar Sinstructions Nave the ocssi bi ic 
imoy of having a variable number of parameters following then 
(these parameters frequently look like "JSR ‘on TPRAP ae 
Structions to the preprocessor). Because of thiS unique 
characteristics the preprocessor will sutomatically or yin tc ius 
the five previous instructions, the sensitive instruction 
encountered, and a message requesting the number of parane> 
ters that are following the instruction. The user can then 
indicate to the oOreprocessor the number of parameters to 
Sk1IP. 

The oreprocessor'’s output is a modified a.out file 
(named evnml0e) void of all sensitive instructions and <2 
sensitive instruction table (named «vmm003) containinae the 
encountered sensitive instructions and their addresses. 

The program logic flow is illustrated in figure i153. 
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iy. Fxecution Monitor 





The execution monitor controls the starting and res~ 
tarting of orocesses executing on the virtual machine. Al} 
processes running under MUNIX have two executable forms. 
The first form is the a.out file for programs ready to be 
executed. The second form 1s the core image file used during 
execution (fiqure 14). The virtual machine monitor frequents 
ly accesses one or both of them (depending on if the process 
has been tnitially executed). During the course Of program 
Beecuei on these two files differ in location. The a.eout 
file is located in the user's library while the core image 
file iSr when not executing, located in the system's swap 
area. 

It the process has never been executedr the execu> 
tion meniicor cimitiates the process’ execution in the seme 
manner (fork, exec) as the oreprocessor was executed (figure 
le). After the user program has initially been executed, 
the execution monitor need onlv issue a CONTIN systen cail. 
This system call puts the core image file, which is current= 
ly blocked for processing, back on the system's process 
ready queue. The execution monitor then issues another WAIT 
system cail to wait for the next interrupt. The execution 
monitor returns to the suoervisor monitor only when the job 
iS comoleted or a breakpoint has been encountered. Figure 
iS illustrates the execution monitor's program loaic. 

Sen DisOatcher 

tihlemadvoeorcierm)y Ss the maim control module for pre= 

cessing virtual mnrachine interrunts. the dispatcher 1s 
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involked when the program executing on the virtual machine 
executes one of the substituted 'TRAP' instructions. 

The dispatcher determines where 1n the program the 
interrupt occurred, the type of interrupt, Ci.e. breakpoint, 
sensitive instructions or normal interrupt) and finally, 
what simulator or function to call. The program logic is 
illustrated in fiqure 16. 

6. Debug Modules 

Plans were oriocinslly made to use the debugging pro 
gramming modules of UNIX, but unfortunately, the debuaging 
program modules were being completely revised to be used 
uncer MUNIX so the decision wasS made to write the virtual 
machine monitor's own debugger. The three primary modules of 
the debugger are the displays, modifys, and breakpoint. 

ae eae 

The display moaule is usec to display the virtu= 
al machine's register values or the virtual machine's memory 
content. (Display commands are outlined in Appnenoix D.) 
Upon command of the user, the values of the general purpose 
registers are disolayed both in actal and decimal number 
rigesentstion while the values of the PS- SPr and PC are 
displayed only in octale Memory may be displayed in octal 
(core dump format) or symbolically. In either case, the 
memory disolay will start from where requested by the uSer 
for the number of words specified. Module logic flow is 
depicted in figure 17. 

The core image file is used to retrieve’ the 
values of the registers and the octal content of memory. 
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DISPLAY 
MEMORY 


SYMBOLIC 


RETURN 








Thus the oroaram must first be executed (produces a core 
imace file) before the use of these two commands are al- 
lowed. 

b. Modify 

The logic flow of the modify module (figure 18) 
is similar to the logic of the previously discussed display 
module. Memory is modified by the modify module on a Honde 
byword basis. As was in display noduler tt is also the case 
here that the progran must first be executed before a regis 
ter is modified. Any memory modification (memory may be 
modified before execution) will automatically modify the 
aeout file and the core image file if it exists. 

ce Breakooint 
-The breakpoint debugging facitity consists of 
two basic functions. One function (BPINSERT) inserts the new 
breakpoint into the user program and the second function 
removes the breakovoint when executed (BPHANDLER). 

Up to ten breakooints at one time can be insert-= 
ed into the program and can be entered either before or dur- 
ing execution (For breakpoint commands see Appendix D). 

(lesb INGER i tunectivom saves the  wrstruction at 
the breakpoint address in an array and inserts a 'TRAP' 
mveds0) instruction in place of it. 

Nhen the breakpoint 18 executed during user pro 
gram execution an interruot occurs and is serviced by the 


BPHANDLR (via the dispatcher). The real instruction 15 


Se) 


returned to the proaram and the program counter (PC3 1 


backed-up one instruction eo lero aie to the returned 
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instruction. A message 1s printed to the user showing the 
instruction address and instruction where the breakpoint was 
inserted. Program control is then returned to the supervisor 
momitor. 

BreakoDdoints are removed upon execution and must 
be re~inserted upon the comoletion of a breakpoint interrupt 
each time the user desires the breakpoint to remain. 

The BPINSERT and BPHANDLR logic flow are illus- 


trated in figure 19. 


D. TEST AND EVALUATION 


Several small standalone programs were written to test 
the reliability and performance of the virtual machine, The 
testina 5 aa ee included executing the porogqram on the vir- 
Bee machine and on the bare machine using the same input. 

All programs tested on the virtual machine executed 1n a 
similar fashion producing the same output es in the stan- 
dalone environment, bout with a Substantial and disaopagintina 
lost of efficiency. For examoler 2@ Small program desiqned to 
echo print a string of chsracters had immediate resoonse-= on 
the bare machiner but took up to twenty seconds wer charac~ 
ter on the virtual mnachine. 

hhe virtual machine s “lack of efficiency 1S mainly 
caused by the need to simulate [/0 to a real devicer the 
user program waiting for execution in the process queue 
after the virtual machine monitor has completed its § funce 


tion, and the need for updating the super=block via the SYNC 
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System call (causes all information 1% core memory that 
should be on disk to be written out) to ewes the user core 
file is located on the disk ‘swap! ares before the virtual 
machine monitor can access the program, 

The efficiency aspect makes the virtual machine under 
its current designe highly impractical for serious utiliza= 
tion, and enphasizes the need for a hardware virtual machine 


extension. 
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V lice ~«CONCL.ULS TN 


The virtual machine with its numerous aoplications pro- 
vides many research opportunities for an educational insti~ 
tution. The virtual machine has proven itself as an extrene- 
ly valuable tool in the university computer laboratorys in 
the computer science classroom as an effective trsining aid, 
sma in the business world aS a Sophisticated approach jn 
Bolving difficult aoplication problems: 

Menatan extremely limited in its current state, the 
PDP-11/50 virtual machine has arrived at the Naval Postgra-~ 
Gduate school. The first milestone has been accomplished. The 
basic foundation for a useable virtual machine with accom= 
panying debugging aids and tools has been completed. The 
virtual machine will execute standealone sorocesses that com- 
form to the stated restrictions. Neverthelessr a great deal 
remains to be accomplished to produce the type of virtual 
machine desirea and needed at the Naval Postgraduate School. 

In our studgyr designry and implementation of this limited 
virtual machine many conclusions, afterthoughts, and recome 
mendations have come to light. The following highlights 


some of our main conclusions and thceughts. 


1. Although we have only developed the embryo 
of the virtual machine, its usefulness is readily 
apparent. For instancer an inexperienced computer 
science student can design a simple assemodler pro- 


gram and actually see and follow the program's 
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execution by examining tne program statuSs, memory, 
and registers. Ne can rapidly obtain an undere 
Standing of data representation versus instruction 
representation, symbolic language versus machine 
lanauager and memory and CPU interaction. Basic 


I/O methods can also be explored. 


ec. Being ambitious is an excellent personal 
travt, but trying to comolete a new Mouse with a 
fancy and beautiful exterior before the foundation 
is comoleted, is catastrophic. A great deal of 
time and effort should be devoted to dividing the 
problem into logical pieces of workable sizes. 
There was a strong desire on our part to complete 
and implement a virtual nachine that satisfied the 
Saeywee School S$ Goals For Virtualization. At 
firsts much time was soent in desianing some of 
the more intricate and final enhancements. It was 
with qreat effort and some loss of pride that we 


limited our goals and establish a milestone ap 


proach. 


53. Being the first to work on brand new 
equipment has a psychological fulfillment, but 
this joy is quickly diminished on encountering the 
ever present new hardware bugs. In the plannina 
phase of new anpndlications that will] be timplemented 
on new hardware (not necessarily unfamilar 
hardware) ‘safety’ factors should be incorporated 
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in the schedule. At worst you are orepared and at 


bestr you finish ahead of scnedule. 


GQ, Like new equinment, unfamiltarity with the 
language adds a new dimension of problems. There 
iS a substantial learning before one can be pro- 
ductive. This takes time, effortr and continuous 


self-discipliner but 1s absolutely essential. 


S.- Many enhancements on the PDP-11/50 were 
being accomplished concurrently tn a coordinated 
team"group sporoach. A marriage of advantages 
exists in this type of real world working environ= 
ment. Few things can be substituted for actual 
experience in a handsson integrated approsch. 
Design considerations must be synchronized with 
the other teamSr working schedules must be coordi-o 
natedr and joint planning meetinas must reguiarity 
be attended. Un the other hand, one is continually 
frustrated by files being destroyed, system 
crashesr unknown system changesr and lack of de> 


tailed coordination. 


Os The program design hss changed consider~ 
ably from the start. It 18 extremely difficuit to 
start by developing programming standards: espe~ 
cially when the lanquage and its characteristics 
are unfamiliar. Much time was Spent an reviewing 


the prooram for possible regrouping and 
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desi 


consolidating program modules. 

The first modules were generally poorly writ- 
tener caused mainly by lanauage unfamiliarity and 
the desire to have the program just work. AS pro 
grammina skills improved, the program modules 
tended to become more sophiscated and clevery and 
resulted in the disguise of the jtogic flow. This 
soon ‘backfires’ on any program of conSiderable 
$size. Special care and time was finally taken to 
improve program modularityr ciaritye and simplicis= 
ty In proaram loaicer eSpecially wnen it was en 
visioned that later enhancements would be added to 
the program by other orogrammers. 

The use of variables was another problsem area. 
They rick be controlled from the beginning or it 
will quickly be too late. Variables should be 
organized to readily distinauish their purpose and 
Should incorporate Some type of naming conventions 
for better omrogram control and wnaintenance. 

One gooa feature of the programr tncorporation 
of an internal procramming ‘debugger’ actuated on 
commandr haS Oroven itself extremely useful and 


valuable. 


As previously mentioned, there is no ‘one best way’ to 


Qn a virtual machinery however access to various 


developed ideas and alternatives 1S a catalyst for 


research, 
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As noted throughout this thesiss there 158 a variety of 
Ongoing ectivity in OfroGgress throwghout the ccuntry concern: 
ing the virtual machine anoproach, but much more work and 
educated orofessionals are needed. The future of the virtu 
al machine at the Naval Postgraduate School will NG © reach 
an acceptable level without careful attention. Many areas 
remain unresolved including the possible acquiring of the 
DEC virtuati machine extensior option and substantially modi- 
fying the ooerating systen to alleviate the I/0 problem. 

Numerous areas of research in virtual machines could be 
recommended for futher researchs but until amore versatile 
virtual machine 1S implemented these arts will have to wait 


or be accomplished at another institution. 
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APPENDEX A 


GLOSSARY 


The purceose of the alossary 18 to provide a brief list 
of the more common definitions found in this thesis and 


related literature, 


fee ARCHITECTURE - Attributes of the system as seen by the 
user. It is the functional behavior and structure of the 
system where emphasis 1S olaced on the needs of the uSer. 

2. BARE MACHINE =~ Machine without its accompanied software. 
3. CONTROL PROGKAM = Generally means virtual machine monito 
4. EXTENDED MACHINE - The bare machine plus operating syse 
tem. 

ae EMULATION ~ Technique to map one system architecture 
into another different architecture usSina some type. of 
firmware support. Enables the computer to execute instruc~ 
tions of other computers. 

Game fAMILY = Series of computers with similiar architectura!) 
design and compoatabilities;, ieee IBM 360 family. 

7. ‘FAMILY VIRTUALIZING = Virtual machine not identical to 
the host but iS 3 member of the same computer family. 

8. GENERATION = Refers to the architectural characteristics 
of the computer, 1.6. second generation and third generation 
computers. 

9. HARDWARE VIRTUALIZER - Hardware-firmware virtual machine 
monitor that supnmorts a virtual machine, i.e. distinct from 


software desiaqn to support a virtual machine. 
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Oa, HYBRID VIRTUA eT Er) | instructions in the 
privelened state are software interpreted. All others are 
executed directly. 

Li. HOST MACHINE = Bare machine in which VMM runs. 

le. NATIVE MODE - Oneration of System, i.@. no emulation. 
Moreen I VELEGED INSTRUCTION = Instructiog that must execute 
only tn the oprivileced mode for correct results. 

Me Se LEP=VIRTUALIZING = The processor of the virtual comput- 
er is 1S identical to the host. 

Mom oC NSITTIVE INSTRUCTION = Am instruction which if permit= 
ted to execute directiy on the host machine will give ine 
correct results because of the virtual machine software con- 
struction. 

Meme coUPERVISOR CALL =~ Instruction used to call upon the 
operseting Syteon 

17. VIRTUAL MACHINE - Isolated duplicate of a real machine. 
Mowe VIRTUAL MACHINE MONITOR - Software which nediates 
between the virtual machine and host, 

Pee UAL MACHINE MONITOR Ty¥rPE Fo Runs on @ bare machine. 
20. VIRTUAL MACHINE MONITOR TYPE I1 = Runs under the host 
machine's ooerating system, 

21. VIRTUALIZATION =~ The creating of a virtual machine. 

Perm vIRTUALIZABLE =~ Refers to being able to create a virtual 
machine fron the existing machine. 

23. VIRTUAL MACHINE RECURSION = Ability to run a virtual 


maenine monitor on a virtual mnachine, 
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APPENDIX C 


SENS TLV soto s 


ire tolvowing POPE 11/50 machine tmseructions were deter- 
mined senSitive. The determination was based on the oremise 
that if the instruction were allowed to be executed either 
(1) the current state of the virtual machine would be tinac- 
curate and/or (2) that the instruction would unitentionally 
interfer with and/or return to the reat system. Jt Should be 
noted that some of these inStructions are only sensitive due 
to the approach selected for producing and operating the 


mm tual machine. 


GROUP 1, - These are the instructions that if exe 
cuted one trap to the real system for interrupt 
mamaling wmmstead of "to the vairtual@machivne inter= 
muligt Randgdters. 
1. HALT - Generates an interrupt in 
user/Sunpervisor moder traps to physical 
address 4. 
e. BPTI = Breakpoint interupt, traps to 
ohysical address 14. 
3. I10T - I/O interruot, traps to physi 
cal address 20, 
GQ. EMT = Emulator interrupt, traos to 
physical address 530. 


5. TRAP - Trap interrupt, traps to phy- 


Sieatbeaccress S54, 
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GeowP Il —"“Lpese are auhe “TmnAStruct items that if exer 
cuted would automatically change the program 
status word (PS). This action must te simulated, 
in a virtuat interupt changing only the virtual 
Boe 

1. RII = Return from trap. 

Gerevll = Returm from trap. 

53. WAIT = It causes the processor to 


relinquish use of the UNIX and wait for 


an externa] interrupt. 


GROUP III = These instructions are desiqned for 
inter=mode communication using the memory manages 
ment unit. A virtualized memory management unit 
1S required for this instruction set. 


1. MFPD = Move from previous data space. 


ec. MIPD = Move to previous data space. 
3. “FPI = Move from previous instruction 
space. 

de Pe ‘= iove to previous instruction 
space. 


GROUP IV - These instructions are NOPs in the 
user/suvervisor mode and should refiect a change 
in the state of the virtual machine. 

1. RESET = All devices on UNIBUS are 

Peset. 

ec. SPL = Sets a new oriority tevel mn 

the PS, 
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GROUP V = Miscellaneous instructions. 
1. “OV - This refers to any MOV instruc- 
tion that references the I/Q page. This 
Instruction is sensitive only due to the 


restriction pleced on the I/0 process= 


ing. 
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USERS MANUAL 
FOR THE 


PDOP=1750 VIRTUAL MAGHHINE 


mee PURPOSE 


This users manual 1S primarly designed to explain now to 
execute programs on the virtual machine and how to use the 


virtual machine's debuaqging capability. 
II]. VIRTUAL MACHINE 


1. Virtual Machine =~ What it is 

A eee CUel machine is basically a software program 
which creates the image and environment of a bare machine fa 
PDP-11/50 without an operatina system). Programs that nore 
mally execute on ae$real bare machine will execute an the 
virtual machine. 

ee Function 

The virtual machine has been used in many soohisti= 
cated apoliceations in the comouter orocessing world. Qne of 
these useSr and the primary one for this machinery 1S an edu~ 
cational aid for the student im computer science. 

Here the student has his own bare PDP=1!1/50 computer 
to progranm and examine the onrogram's execution. The virtual 
machine will execute stand-alone PDP#11/50 assembler fro- 
grams that meet the restrictions in section VII. 
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Ss. DODebuggmnoaGepabi lity 
The virtual machine has a simple but Significant 
debugging capability. The student veon 9 disolay ang modity 
the general ourpose registerSre program counters, stack 
pointers, and program status word. He can also disolay = and 
modify memory. He can insert breakpoints at certain areas 
ef his program for controlled program execution. 
4. Configuration 
The virtual machine's configuration is as follows: 
ae One POR Sav computer (without memory 
management). 
be. 32k words of memory. 


Ge One LASOSOURC writer terminal. 
Mit. INPUT TO THE VIRTUAL MACHINE 


Jobs to be processed on the virtual machine must con- 
form to the following characteristics. They must? 

1. be POP#11/50 assembly programs. 

me) De 61M a. Out file format. 

3. have non=shareabdle program segments. 

4. not incorporate any UNIX system calls. 

5. have been preprocessed by the virtual machine tioni> 
tor. 


Ps 


IV. GENERAL FLOW IN USING THE VIRTUAL MACHINE 


i. Programmer desiqnsr proaramSs and assembles his pro 


gram. 


e. User starts up the program ‘evmm'. 
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5. User preprocesses his assembled program using the 
preprocessor command of the virtual machine. 

a. Programmer, may if he desires, insert breakpoints 
meco his orogram at critical arees. 

5. User executes his proaram usSing the execute command 
of the virtual machine. 

6. Programmer can at anytime while his job is not actu 
ally executing on the virtual machine, utilize any debug 
function. 

7e When program has terminated, user can stop the vir= 


tual machine by the termination command. 
Ve. VIRTUAL MACHINE COMMANDS 


The following 1s a list of the valid commands and their 
resnective functions. Al) addresses (ADDR) and required 
values (VALVE) must be expressed in octal. 


COMMAND FUNCTION 


p filex [y/n] Preprocess filex. This com- 
mand has one optional parame 
ter. The parameter indicates 
whether the user wants to be 
informed when a sensitive 


instruction is encountered. 


e Start or continue program exe 
CUt Tome, 
b ADOR Put a breakpoint at address 
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ADDR 


ao Ff Display all qeneral register 


plus the program status word. 


Geeo ADDR # Display memory starting fron 
eddress ADDR for # number of 


words. 


dG s ADDR # Disolay the program symbolic 
cally from address ADDR for 4 


number of instructions. 


m rX VALUE Modify register X to VALUE 
moe 8 6VALUE Modify stack pointer to VALUE. 
m PC ADOR Modify the program counter 


with address AOODR. 


fae 6M ALUE Modify the program status word 
to VALUE. 

m mem ADDR VALUE Modify memory at address ADDR 
fom VR Wit. 

S Terminate the execution of the 


virtual machine monitor. 


Weer ate ROCESSOR 


The prenprocessor examines the user's programs for sensi” 


mEveutnetructions CinsStrPuctions that can not be allowed to 
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directly execute). As isllustrated above in the virtual 
machine commandsry the preorocessor has two parameters. The 
first parameter is manditory and is the user's program nane; 
the second oarameter is optional, allowing the user a choice 
of whether he wants to be notified when a sensitive instruc- 
tion 1s encountered. When notification is desired, the sen- 
Sitive instruction plus the five previous instructions of 
the program and their location will be displayed. After 
Examining these instructions the User cam agree Grmdcisaqree 
with the oreprocessor. The user's decision iS accepted by 
the preprocessor so user BEWARE. 

The 'JSR' and 'TRAP' instructions have the possibility 
of having a variable number of parameters following them 
menese Parameters frequently Wook like Sensitive instruc 
tions aoeone preprocessor). Because of this unique charac- 
teristicr the preorocessor will automatically printout the 
five previous instructions, the 'JSR' and 'TRAP' instruction 
encountered, and a message requesting the number of parane- 
ters that are followina the instruction. The user can then 
Indicate to the preprocessor the number of carameters =O 


Skip. 
ter. BASIC RULES AND RESTRICTIONS 


1, Ali files must be an aeout file and be preprocessed 
before any command will functi0On on the virtuati machine 
including file execution. 

e. All files will) be stand-alone type processes, and 
must not use any UNIX system calls CREAD, WRITE, EXIT, 
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3. Files cannot employ any interrupt type processing. 

4. Files must perform their own J/0 routines. I/0 is 
restricted in the method veea to -acececs the A707 oeqge.s Ali 
access to the I/0 page wili be performed only by the ‘MOV' 
instruction, and then only by direct indexing. I/O access> 
ing is limited to the four LA30 DECwriter registers. (see 
DEC peripherals handbook). 

S. File must first be executed before displaying or 
modifying registersr or in displaying memory itn octal. 

6. Files will use the 'HALT' instruction for normal 
exiting from thetr program, 

7. (‘The following assembler instructions will be treat- 
ed as NOP instructions: MFPD, MTPD, MFPI, MIPI, RESETe WAIT, 
mig RTT? and SPL- 

8. The user should be cauttoned against Inserting a 
breakpoint within an I/0 Cloop) routine that tnputs a string 
of characters. When a breakpoint 1s encountered the remain= 


ing characters for itnsertion will be lost. 


VIII. FILE NAMES AND FUNCTION 

i. ‘evmm' = Name of the virtual machine monitor pro- 
gram the Sails creates and controls the virtual machine. 

ale 'evmp001' = Name of the preprocessor program. 

Ses "Eevmm002' =~ Name given to the user program after 
user proaram is 1S modified by the oreprocessor. 

GQ. ‘feyvmt003' = An array of sensitive instructions and 


addresses 1n the user program by the preprocessor, 
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